done :)) https://hackage.haskell.org/package/hdf5-1.8.12 thanks a lot Fred

I opened a bug in order to add hdf5 in the infra for the doc generation. We will see if something happens. haskell/hackage-server#1326 Cheers Fred

Now that I package it , I get this error message when using in on my Debian unstable... ``` [11 of 35] Compiling Hkl.Orphan ( src/Hkl/Orphan.hs, /home/picca/src/repo.or.cz/hkl/binoculars-ng/dist-newstyle/build/x86_64-linux/ghc-9.4.7/hkl-0.1.0.2/build/Hkl/Orphan.o, /home/picca/src/repo.or.cz/hkl/binoculars-ng/dist-newstyle/build/x86_64-linux/ghc-9.4.7/hkl-0.1.0.2/build/Hkl/Orphan.dyn_o ) <no location info>: error: /usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-9.4.7/libHShdf5-1.8.12-7vN30ONv9AwlCS4i14H8u-ghc9.4.7.so: undefined symbol: H5Sencode2 [22 of 35] Compiling Hkl.Binoculars.Config ( src/Hkl/Binoculars/Config.hs, /home/picca/src/repo.or.cz/hkl/binoculars-ng/dist-newstyle/build/x86_64-linux/ghc-9.4.7/hkl-0.1.0.2/build/Hkl/Binoculars/Config.o, /home/picca/src/repo.or.cz/hkl/binoculars-ng/dist-newstyle/build/x86_64-linux/ghc-9.4.7/hkl-0.1.0.2/build/Hkl/Binoculars/Config.dyn_o ) <no location info>: error: /usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-9.4.7/libHShdf5-1.8.12-7vN30ONv9AwlCS4i14H8u-ghc9.4.7.so: undefined symbol: H5Sencode2 Error: cabal: Failed to build hkl-0.1.0.2 (which is required by exe:binoculars-ng from hkl-0.1.0.2). ```

Indeed, I have hdf 1.10 and this H5Sencode2 is only available in 1.12...

This is because the check is over something unrelated.. https://portal.hdfgroup.org/hdf5/v1_14_4/api-compat-macros.html this page explain that there is a H5XXXX_vers = parameter per symbols... I link against the 1.10 version which does not contain this H5Sencode1 and 2 I am wondering if the Raw binding should not provide all the symbols depending only on the HDF5 version. with something like H5_VERSION_GE(x, y, z) in order to expose the symbols. To my opinion the non Raw API should not deal with all these version and just use the Macro version. I am wondering if the hdf5 binding should deal with these XXX_vers parameters at all...

Yes ifdef but based on the version of the hdf5 library :) not these _vers parameters.

I endup with this in the Raw Binding. ``` #if H5_VERSION_GE(1,12,0) # if H5Sencode_vers == 1 && !H5_NO_DEPRECATED_SYMBOLS #ccall H5Sencode1, <hid_t> -> OutArray CChar -> InOut <size_t> -> IO <herr_t> h5s_encode = H5Sencode1 # else #ccall H5Sencode2, <hid_t> -> OutArray CChar -> InOut <size_t> -> <hid_t> -> IO <herr_t> h5s_encode = H5Sencode2 # endif #else #ccall H5Sencode, <hid_t> -> OutArray CChar -> InOut <size_t> -> IO <herr_t> #endif ``` It seems to mimic the hdf5 library logic. Now the problem is what to do in the higher level API... the h5s_encode signature is different depending on the library version or the compile parameter. So at some point we will need to decide whcih API should be called. so we need to deal with the same logic in the high level API... Create an ``` encodeDataspace1 :: Dataspace -> IO BS.ByteString encodeDataspace1 (Dataspace space_id) = withOutByteString $ \buf bufSz -> withInOut_ bufSz $ \ioBufSz -> withErrorCheck_ $ h5s_encode space_id buf ioBufSz ``` and an encodeDataspace2 then selec the default encodeDataspace = ... depending on the hdf5 version... The issue I see wit this is that the API change depending on the hdf5 library. The other solution is to keep for now the current API and deal with the gory details inside encodeDataspace liek you did before.